You Should Better Enforce Than Verify

This tutorial deals with runtime enforcement and advocates its use as an extension of runtime verification. While research efforts in runtime verification have been mainly concerned with detection of misbehaviors and acknowledgement of desired behaviors, runtime enforcement aims mainly to circumvent misbehaviors of systems and to guarantee desired behaviors. First, we propose a comparison between runtime verification and runtime enforcement. We then present previous theoretical models of runtime enforcement mechanisms and their expressive power with respect to enforcement. Then, we overview existing work on runtime enforcement monitor synthesis. Finally, we propose some future challenges for the runtime enforcement technique. Runtime verification [1, 2] is a well established technique which consists in using a monitor to supervise, at runtime, the execution of an underlying program against a set of expected properties. A monitor is a decision procedure with an output function (e.g., a state machine when dealing with regular properties) processing (step by step) an execution sequence of the monitored program, and producing a sequence of verdicts (truth values of a truth-domain) indicating fulfillment or violation of a property. Whilst the detection might sometimes be a sufficient assurance for some systems, the occurrence (resp. non-occurrence) of property violations (resp. validations) might be unacceptable for others. Runtime enforcement [3–6] of the desired property is a possible solution to ensure expected behaviors and avoid misbehaviors. Within this technique the monitor not only observes the current program execution, but also modifies it. It uses an internal memorisation mechanism, in order to ensure that the expected property is fulfilled: it still reads an input sequence but now produces a new sequence of events in such a way that the property is enforced. The precise and formal relation between input and output sequences is usually ruled by two constraints: soundness and transparency. From an abstract point of view, those constraints entail the monitor to minimally modify the input sequence in order to ensure the desired property. When the program behaves well, the enforcement monitor lets the program execute with the least influence. If the program behavior is about to exhibit a deviation w.r.t. the expected property, the monitor uses its internal memorization mechanism to prevent the misbehavior. Practical applications of runtime enforcement. There have been many practical applications of the theory of runtime enforcement (e.g., in [7–9] for program safety, or in [10, 11] for access control policies). Most of them are built on ⋆ A longer version with more results and examples is available on the author’s webpage. Schneider’s model of security automata. Although in this tutorial we will see an ideational difference between enforcement and verification, in practice there is not always a clear distinction between these disciplines. As so, even early runtime verification frameworks were often designed to, say, “execute some code” when a property is violated; hence modifying the initial program execution. For instance, when a property gets violated: – JPAX [12], RMOR [13] allow to specify call-back functions that get called; – Temporal Rover [14] allows to specify a bunch of code to be executed; – MOP [15] augments monitors with exception handlers. Nevertheless, reactions to errors are seldom used or at least lacks a systematic and formal study. Furthermore, it is clear that preventing bad behaviors would be more desirable than providing reactions to them (“better safe than sorry”). Tutorial outline. This tutorial focuses on the efforts towards building a theory of runtime enforcement which is, as we believe, emerging as a new activity. We advocate its use as an important complementary activity to runtime verification. 1 Underlying concepts Given an alphabet E, a sequence σ on E is a total function σ : I → E where I is either the interval [0, n] for some n ∈ N, or N itself. The empty sequence is denoted by ǫ. We denote by E the set of finite sequences over E and by E the set of infinite sequences over E. E ∪E is noted E. We will assume some familiarity with the notions of sequence, prefix, and continuation. We will use σ···n, for n ∈ N \ {0}, to denote the prefix of σ of length n. Execution sequences. In runtime verification and enforcement techniques, as we are not aware of the program specification, the monitored program is often regarded as a generator of sequences. Thus, the runtime activity focuses on a restricted alphabet Σc of concrete events or operations the program can perform. Such sequences can be made of e.g., resource-access events on a secure system, or kernel operations on an operating system. In a software context, these events may represent a relevant subset of instructions (e.g., variable modifications or procedure calls). These operations determine the truth value of properties. Thus, in order to compare program’s executions with the property, these concrete events should be abstracted in a finite set of abstract events Σa. This abstraction is an underlying correspondence Σc ↔ Σa, mapping every occurrence of a concrete event to the occurrence of an abstract event. To simplify notations, in this tutorial we will talk uniformly about execution sequences, and use a unified alphabet Σ. Execution sequences, i.e., possibly non-terminating runs, range over Σ. Policies vs properties. As often referred in the verification literature, a property is a set of single execution sequences, i.e., a property partitions the set of possible execution sequences. Schneider [3] distinguishes properties from policies. A policy is defined over sets of execution sequences, i.e., a policy partitions 1 This is exactly the purpose of program instrumentation (cf. Section 2.1). Note also that the problem might be slightly more complex when dealing with parametric events, events that also depend of concrete execution values (see. [16] for instance).